!•■•  I.  k' 


oL 


o 


s^ 


D£V«- 


HD28 
.M414 


WORKING  PAPER 
ALFRED  P.  SLOAN  SCHOOL  OF  MANAGEMENT 


Augmenting  the  House  of  Quality 
with  Engineering  Models 


by 

Rajan  Ramaswamy 
Karl  Ulrich 


WP  #3456-92 


August  1992 


MASSACHUSETTS 

INSTITUTE  OF  TECHNOLOGY 

50  MEMORIAL  DRIVE 

CAMBRIDGE,  MASSACHUSETTS  02139 


Augmenting  the  House  of  Quality 
with  Engineering  Models 

by 

Rajan  Ramaswamy 

Karl  Ulrich 

WP  #3456-92  August  1992 


MASSACHIJSFTTS  INSTITUTE 

JAN  04  1996 

L13RABIES 


Augmenting  the  House  of  Quality  with 
Engineering  Models 


Raj  an  Ramaswamy 

Karl  Ulrichi 

Massachusetts  Institute  of  Technology 


Abstract 

To  develop  successful  products  the  "Voice  of  the  Customer"  must  be  explicitly 
considered  in  the  design  process.  The  House  of  Quality  is  an  increasingly  popular 
structured  methodology  for  ensuring  customer  focus.  In  this  paper,  we  describe 
preliminary  work  on  augmenting  the  House  of  Quality  through  the  use  of  engineer- 
ing models  of  product  performance.  Using  an  example  drawn  from  practice,  we 
discuss  practical  problems  with  using  the  House  of  Quality  and  show  how  infor- 
mation from  engineering  models  can  be  used  to  solve  some  of  these  problems.  We 
identify  some  of  the  potential  benefits  of  this  approach  and  show  how  engineering 
models  and  the  information  contained  in  the  House  of  Quality  can  be  unified  in  a 
single  representation. 

Keywords:  House  of  Quality,  modeling,  design,  product  development,  represen- 
tation 
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1      Introduction 

The  degree  to  which  a  product  satisfies  customer  desires  is  a  critical  product  success 
factor  [HOPM90,  HOMP89].  A  consensus  is  rapidly  developing  in  industrial  practice 
that  customer  desires  can  only  be  obtained  from  actual  contact  with  the  customer  and 
that  designers  are  often  wrong  when  they  try  to  guess  what  the  customer  wants  [GR\V86, 
RMS3,  Ran89,  SC78,  UH80].  To  facilitate  customer  focus,  several  structured  methodolo- 
gies for  organizing  and  presenting  customer  information  have  been  developed.  One  such 
methodology  is  the  House  of  Quality  (HOQ),  which  helps  product  designers  to  identify 
explicitly  customer  requirements,  relate  them  to  objective  engineering  characteristics, 
identify  tradeoffs,  and  to  evaluate  the  characteristics  of  a  potential  product  relative  to 
competing  products  [CH88]. 

The  HOQ  is  most  often  used  to  set  targets  for  the  engineering  performance  of  a  prod- 
uct. In  a  typical  situation,  marketing  staff  collect  data  about  customers  and  competing 
products  and,  with  some  input  from  engineering,  decide  a  set  of  performance  targets 
which  are  then  communicated  to  the  designers.  In  this  paper  we  address  two  weaknesses 
of  this  methodology, 

1.  Targets  set  on  customer  information  alone  are  often  unrealistic.  Hence  designers 
cannot  achieve  them  and  this  results  in  time-consuming  iterations  until  a  compro- 
mise is  reached. 

2.  The  roof  of  the  HOQ  alone  cannot  adequately  capture  the  complex  coupling  be- 
tween design  variables.  Hence  the  trade-offs  that  must  be  made  in  the  design  are 
over-simplified  or  even  ignored. 

We  believe  that  engineering  models,  if  used  in  conjunction  with  the  HOQ,  can  help 
address  these  problems. 

Designers  often  have  rehable  engineering  models  which  they  can  use  to  test  the  limits 
of  product  performance  [RUKT91].  The  inputs  to  these  models,  the  design  variables,  are 
the  actual  quantities  that  the  designer  can  control  and  the  outputs  are  the  important 
performance  metrics  of  the  product.  Engineering  models  can  therefore  be  a  valuable 
tool  for  exploring  design  tradeoffs  and  product  performance  without  building  extensive 
prototype  hardware. 

In  this  paper  we  show  how  by  having  access  to  engineering  models  and  the  HOQ 
simultaneously,  designers  may  more  rapidly  and  reliably  produce  designs  that  satisfy  the 
customer.  Specifically,  we  examine  shortcomings  of  the  HOQ  which  manifest  themselves 
when  it  is  used  in  a  real  design  project  and  show  how  augmenting  it  with  mathematical 
models  of  product  performance  helps  solve  some  of  these  problems.  We  illustrate  all  our 
arguments  with  an  example  derived  from  an  ongoing  project  with  an  industrial  sponsor 
to  design  a  hand-held  power  tool.  To  protect  our  sponsor's  proprietary  data,  we  present 
our  ideas  using  the  design  of  a  cordless  drill  as  the  example.   The  actual  project  is  not 
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Figure  1:  Tool  Concept  (schematic) 

a  drill,  but  shares  almost  all  of  the  same  design  issues.  The  general  statement  of  the 
disguised  design  problem  is, 

Develop  a  hand-held  cordless  drill  for  the  professional  market  which  will  take 
up  to  10mm  bits  and  be  superior  to  existing  competing  products. 

We  further  assume  that  we  are  at  a  point  in  the  development  process  where  we  have 
chosen  a  basic  tool  concept.  A  schematic  description  of  the  tool  concept  is  shown  in 
Figure  1.  We  will  show  how  some  fairly  difficult  decisions  must  be  made  even  for  this 
simple  product  and  how  the  HOQ  and  an  engineering  model  can  help  designers  when 
making  these  decisions. 

1.1      Roadmap 

We  first  provide  some  general  background  on  the  HOQ  and  discuss  the  information  stored 
in  it  for  the  cordless  drill  design  example.  We  then  point  out  some  of  the  shortcomings 
of  the  HOQ  approach,  which  we  have  noticed  in  the  course  of  attempting  to  apply 
it.  Subsequently  we  describe  an  engineering  model  of  performance  for  the  drill  design 
example  and  show  how  references  to  it  can  be  used  to  correct  some  of  the  problems 
with  using  the  HOQ.  The  idea  of  storing  the  HOQ  and  performance  models  in  a  single 
representation  to  facihtate  access  and  usage  is  then  introduced.  We  conclude  with  a 
summary  of  the  key  ideas  and  an  outline  of  work  planned  for  the  future. 


2      Using  the  House  of  Quality 


In  this  section,  we  describe  the  HOQ  and  explain  its  use  for  the  cordless  drill.  Readers 
familiar  with  the  HOQ  technique  should  skim  the  generic  parts  and  concentrate  on  por- 
tions related  to  the  design  example.  Figure  2  contains  important  information  about  the 
example  and  should  be  carefully  examined  and  understood  before  proceeding. 
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Figure  2:  HOQ  for  design  of  cordless  drill 


The  House  of  Quality  (HOQ)  is  a  tool  for  relating  the  consumers'  desires  {customer 
attributes  in  HOQ  parlance)  to  technical  performance  specifications  [engineering  charac- 
teristicsin  HOQ  parlance).  Customer  attributes  collected  through  surveys  and  interviews 
are  usually  phrased  in  day-to-day  language  and  are  not  suitable  for  direct  use  in  an  en- 
gineering project.  The  important  objective  of  the  HOQ  technique  is  to  help  a  product 
development  team  translate  the  customer  attributes  into  formal  engineering  targets  and 
to  store  the  information  necessary  for  this  translation  in  a  readable,  understandable  for- 
mat. The  HOQ  related  to  the  design  of  a  cordless  drill  is  displayed  in  Figure  2.  Its 
elements  are: 

•  Customer  Attributes  (CAs):  The  CAs  are  usually  actual  statements  made  by  cus- 
tomers during  interviews  and  surveys.  For  example  in  Figure  2,  "Can  use  tool 
continuously"  and  "Tool  is  powerful"  are  quotes  from  actual  customer  statements. 
Note  also  that  the  CAs  shown  are  actually  group  headings  that  arose  from  arranging 
the  raw  customer  statements  into  related  groups  and  then  picking  one  statement 
which  was  representative  of  the  whole  group.  Estimates  of  the  relative  importance 
of  the  CAs  (a  total  of  100)  are  typically  displayed  in  a  column  adjacent  to  the  CA 
names  (see  Figure  2). 

•  Engineering  Characteristics  (ECs):  The  ECs  are  the  system- level  technical  product 
performance  characteristics  that  influence  the  customer  attributes.  The  designer 
must  be  able  to  assign  ECs  a  numerical  value  and  a  unit.  Usually  ECs  cannot 
be  fully  identified  until  a  basic  product  concept  has  been  selected.  The  values  in 
the  "body"  of  the  HOQ  (described  next)  and  the  relative  importances  of  the  CAs 
can  be  used  to  impute  importances  to  each  EC.  These  values  are  stored  as  part 
of  the  supplementary  information  in  the  HOQ.  Further,  a  -|-  or  —  sign  below  each 
EC  indicates  if  the  designer  wishes  to  maximize  or  minimize  that  value.  In  our 
example,  mass  is  labelled  with  —  and  max.  power  is  labelled  with  -f-  because  a  tool 
with  low  mass  and  high  power  is  desirable. 

•  "Body":  This  is  a  matrix,  having  rows  labeled  with  the  CAs  and  the  columns  la- 
beled with  the  ECs,  whose  entries  indicate  the  strength  of  the  relationship  between 
CAs  and  ECs.  In  other  words  each  entry  indicates  how  strongly  the  designer,  by 
changing  the  EC,  can  affect  the  aspect  of  customer  satisfaction  represented  by  the 
CA.  Entries  in  the  body  may  be  symbols  or  numbers  indicating  the  strength  of  the 
relationship.  We  use  numbers  on  a  scale  from  0  to  10  in  our  work  (blank  spaces  in 
the  body  in  Figure  2  have  value  0).  Figure  2  shows,  for  example,  that  there  are  two 
aspects  to  making  the  customers  feel  that  they  "Can  use  tool  continuously"-u'orfc 
output  is  the  major  factor  (weight  9)  and  mass  a  comparatively  minor  one  (weight 
3). 


• 


"Roof":  The  roof  helps  record  how  ECs  interact  with  other  ECs.  Engineers  often 
have  to  "balance  tradeoffs  when  addressing  customer  benefits"  [CH88,  GBW92] 
and  hence  it  is  useful  to  have  answers  to  questions  such  as  "Will  lowering  the  mass 


have  any  effect  on  max.  power?"  The  answers  to  such  questions  are  stored  in  the 
"roof"  of  the  HOQ,  once  again  in  matrix  form.  An  entry  corresponding  to  two 
ECs  indicates  that  the  two  are  related.  In  one  of  the  early  papers  on  the  subject 
Clausing  and  Hauser  [CH88],  use  the  symbols  x  and  \/  to  indicate  "negative"  and 
"positive"  relationships  between  ECs.  For  example.  Figure  2  shows  that  mass  and 
max.  power  have  a  negative  relationship,  indicating  that  improving  the  tool  power 
will  worsen  the  tool  mass.  However,  we  will  shortly  illustrate  why  such  simplistic 
measures  of  coupling  are  inadequate  in  real  design  situations. 

Supplementary  Information:  The  portion  of  the  HOQ  below  the  body  is  used  to 
store  miscellaneous  useful  information  such  as  target  values  for  each  EC.  units. 
and  values  of  that  EC  for  competitors'  products  (for  benchmarking  purposes).  .\ 
particularly  important  row  is  the  one  giving  the  imputed  importances  for  the  ECs. 
This  is  computed  for  each  EC  as  the  weighted  sum  of  the  correlations  with  CAs 
(the  relative  importance  for  each  C.\  is  the  weight).  These  values  are  analogous 
to  the  relative  importances  of  the  CAs.  They  help  guide  decisions  which  hinge  on 
deciding  which  EC  to  change  so  as  to  realize  the  maximum  possible  improvement 
in  customer  perception.  Often  the  HOQ  includes  a  region  along  the  right  side  of 
the  body  to  show  the  relative  performance  of  each  competitor's  product  for  each 
C.\.  This  is  called  a  perceptual  map  in  marketing  jargon.  We  have  not  shown  this 
information  in  Figure  2.  Of  course,  other  relevant  data  may  also  be  stored  in  the 
supplementary  area  and  in  fact  customization  to  suit  individual  design  problems  is 
encouraged. 


3      Two  Problems  with  the  HOQ  Methodology 

The  key  benefits  of  the  HOQ  methodology  are  that  it  helps  designers  answer  two  funda- 
mental questions.  These  are  (paraphrased  from    [CH88]). 

•  How  can  designers  influence  customer-perceived  qualities  and  by  how  much? 

•  How  does  an  engineering  change  affect  other  characteristics? 

Let  us  examine  how  well  the  HOQ  helps  the  designer  answer  these  two  questions. 

The  HOQ  performs  the  important  function  of  telling  the  designers  how  they  currently 
stand,  i.e.  how  their  product  stacks  up  against  competing  products  both  in  terms  of 
customer  perception  and  engineering  numbers.  This  information,  combined  with  the 
correlation  information  from  the  body,  can  be  used  to  set  targets  on  the  various  ECs 
which  will  enable  the  product  to  outstrip  all  the  competitors.  When  attempting  to 
achieve  these  targets  the  information  in  the  roof  is  intended  to  ensure  that  no  EC  is 
improved  at  the  (unreasonable)  expense  of  another. 

However,  the  HOQ  does  not  take  into  account  two  important  factors. 


•  Setting  targets  is  of  no  use  unless  these  targets  are  realistically  achievable.  Using 
customer  and  competitor  information  alone  to  set  targets  will  often  result  in  targets 
that  can  never  be  achieved  in  practice.  ECs  cannot  be  set  directly,  they  can  only 
be  indirectly  controlled  via  the  design  variables  for  the  problem. 

•  The  nature  of  coupHng  between  ECs  can  be  quite  complex  and  this  cannot  be  stored 
in  the  roof  of  the  HOQ  because  of  its  extremely  limited  ability  to  accurately  record 
tradeoffs.  In  a  typical  design  situation,  two  ECs  will  have  several  common  design 
variables  eind  the  behavior  with  respect  to  each  of  these  variables  may  be  different. 
Hence  it  is  not  possible  to  characterize  the  true  tradeoff  with  just  a  single  symbol 
representing  a  positive  or  negative  relationship. 

\\'e  beheve  that  these  problems  are  best  solved  or  at  least  alleviated  through  the 
use  of  engineering  models,  which  are  mathematical  models  of  product  performance.  To 
reinforce  our  assertion,  we  introduce  an  engineering  model  for  the  drill  example  and  show 
how  it  can  be  used  to  solve  the  above  problems. 


4     How  Do  Engineering  Models  Help? 

Many  firms,  manufacturing  products  ranging  from  bearings  to  jet  engines,  have  developed 
engineering  models  for  their  products  (for  an  example  from  the  domain  of  automobile 
design,  see  [RUKT91]).  These  models  are  used  to  decide  whether  designs  are  feasible, 
to  explore  the  performance  envelope  of  a  design  without  actually  building  a  physical 
prototype,  and  to  study  the  tradeoffs  involved  in  the  design.  .-Xn  engineering  model  is  a 
mathematical  model  that  relates  the  design  variables  to  the  performance  metrics  used  to 
quantify  performance  of  a  product.  For  example,  the  engineering  model  for  the  cordless 
drill  relates  design  variables  such  as  number  of  cells  and  motor  choice  to  performance 
metrics  such  as  maximum  power  and  m.ass. 

The  structure  of  an  engineering  model  for  the  cordless  drill  example  is  shown  in 
Figure  3.  The  variables  (e.g.  motor  choice  and  transmission  ratio)  on  the  extreme  right 
are  the  design  variables  for  this  problem  and  those  on  the  extreme  left  (e.g.  max.  power 
and  mass)  are  the  performance  metrics.  Some  intermediate  variables  such  as  motor 
torque  and  overall  efficiency  are  computed  for  convenience.  The  structure  of  the  network 
in  Figure  3  is  such  that  if  values  are  specified  for  all  the  design  variables,  the  performance 
metrics  can  be  computed  from  them  without  iteration.  As  shown  in  the  figure  causality 
flows  from  right  to  left  in  the  network. 

Using  an  engineering  model  to  calculate  numerical  values  for  the  performance  metrics 
is  only  one  use  that  it  can  be  put  to.  Another  major  benefit  is  the  insight  it  can  offer 
into  the  topology  of  the  design  problem.  Network  representations,  such  as  the  one  shown 
in  Figure  3.  make  it  easier  for  the  designer  to  understand  which  design  variables  affect 
a  particular  performance  metric,  how  strongly  coupled  a  metric  is  with  another  one  and 
so  on. 
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Figure  3:  Engineering  Model  for  Cordless  Drill 


Engineering  models  are  useful  in  conjunction  with  the  HOQ  because  they  complete 
the  chain  from  the  entities  the  designers  can  actually  change,  the  design  variables,  to 
what  the  designer  wants  to  affect,  customer  perception  of  the  product.  We  now  describe 
two  important  ways  in  which  an  engineering  model  linking  design  variables  to  the  EC's 
of  the  HOQ  can  help  us  address  the  weaknesses  in  the  HOQ  methodology. 


4.1      Setting  Reasonable  Targets 

One  of  the  principal  benefits  of  the  HOQ  methodology  is  that  it  enables  subjective  cus- 
tomer data  to  be  translated  into  concrete  performance  targets.  For  example,  the  state- 
ment "Want  to  use  tool  continuously"  does  not  give  a  designer  much  useful  information, 
but  a  desired  mass  of  2.0  kg  and  max.  power  oi  100  W  make  the  design  problem  much 
better  defined.  Data  from  the  HOQ  about  customer  perception  and  competing  products 
is  often  used  to  determine  performance  targets  for  a  design.  These  targets,  if  achieved, 
will  raise  customer  perception  of  the  product  above  that  of  any  competitor. 

Unfortunately,  this  is  not  always  a  fool-proof  strategy.  Very  often,  the  targets  set 
are  not  achievable  and  designers  may  expend  considerable  resources  explaining  why  the 
targets  are  not  achievable,  deciding  new  targets,  and  creating  a  design  that  satisfies 
the  new  targets.  Targets  set  based  on  only  customer  and  competitor  information  seem 
especially  prone  to  this  outcome. 

Consider  the  case  of  the  cordless  drill  and  the  ECs  mass  and  work  output.  Figure  3 
shows  that  work  output  is  related  to  energy  and  overall  efficiency.  Let's  try  to  change 
these  by  changing  energy  which  is  in  turn  decided  by  the  battery-related  design  parame- 
ters (assume  a  fixed  value  for  the  overall  efficiency).  The  engineering  model  shows  that 
energy  goes  up  if  number  of  cells  is  increased.  However,  this  also  increases  battery  mass 
and  therefore  mass,  indicating  that  work  output  can  only  be  increased  at  the  cost  of  a 
heavier  tool.  Yet  customers  want  low  mass  and  high  work  output  simultaneously. 

Now  assume  that  there  are  two  competitors,  Cl  and  C'2  already  on  the  market.  Cl's 
market  research  indicates  that  customers  don't  mind  a  heavy  tool  if  it  has  a  high  work 
output,  i.e.  they  don't  have  to  recharge  it  as  often.  C2's  philosophy  is  that  the  customer 
must  not  get  tired  before  the  battery  runs  out  and  hence  they  offer  a  lighter  tool  which 
has  to  be  recharged  more  often.  The  data  from  both  these  competitors  and  for  our 
product  is  indicated  in  the  following  table. 


Competitor 
Name 

Tool 
Mass  (kg) 

Battery 

Mass(kg) 

Work 
Output  (kJ) 

Cl 
C2 

Us 

1.59 

1.25 

1.3 

0.35 
0.30 
0.33 

25 
23 
23 

If  the  best  competitor  values  are  selected  as  the  targets  for  the  ECs,  the  targets 
would  be  a  mass  of  1.25  kg  and  a  work  output  of  25  kJ.  Let  us  temporarily  assume  that 


the  battery  is  the  only  component  that  is  to  be  changed,  and  that  overall  efficiency  is 
currently  60%.  Hence  to  get  a  work  output  of  25  kJ  at  60%  efficiency,  the  battery  must 
store  25/0.6  =  41.7  kJ.  Current  mass  of  our  tool  without  battery  is  0.97  kg  and  and 
hence  the  battery  can  weigh  a  maximum  of  0.28  kg  to  meet  the  1.25  kg  total.  Hence  the 
energy  density  required  is  41.7/0.28  =  149  kJ/kg.  Now  both  competitors  are  using  the 
same  battery  which  supplies  around  130  kJ/kg,  which  is  close  to  the  industry  standard. 
Therefore  to  meet  the  149  kJ/kg  demand  made  on  the  battery  is  probably  unrealistic. 
The  engineering  model  can  include  a  number  of  such  checks  to  ensure  that  designs  are 
physically  realizable  given  the  existing  technology.  Hence,  had  the  model  been  consulted 
w'hen  this  specification  was  created,  it  would  have  been  clear  that  the  specification  was 
unreasonable. 

A  further  examination  of  Figure  3  shows  that  work  output  is  affected  by  the  overall 
efficiency  .  Hence  improving  the  efficiency  is  another  potential  way  of  satisfying  the 
targets  if  it  is  found  that  batteries  are  fimited  to  130  kJ/kg.  Another  check  can  now 
be  performed  by  computing  the  overall  efficiency  that  would  be  required  to  meet  the 
specification.  0.28  kg  of  the  130  kJ/kg  batteries  will  provide  36.4  kJ  at  100%  efficiency 
and  the  tool  must  provide  25  kJ,  hence  dictating  an  overall  efficiencyoi'2b/Z6A  =  68.6%. 
A  further  judgment  can  then  be  made  on  whether  this  is  reasonable  or  not. 

We  have  shown  in  the  preceding  example  how  the  engineering  model  can  be  used  in 
conjunction  with  the  HOQ  to  create  a  more  reliable  and  reahstic  specification  process. 
In  some  cases,  technological  advances  can  be  made  in  order  to  break  the  bounds  of 
the  model  predictions.  However,  the  engineering  model  ensures  that  the  development 
team  knows  when  targets  are  within  the  bounds  of  available  technology  and  when  an 
alternative  technology  is  the  only  way  to  achieve  a  performance  target. 


4.2      Managing  Trade-ofFs 

The  HOQ  explicitly  acknowledges  the  inherently  contradictory  nature  of  typical  ECs  or 
performance  metrics  and  hence  attempts  to  provide  a  facility  for  balancing  contradictory 
ECs.  This  facihty  is  the  roof  of  the  HOQ,  which  is  used  to  tell  an  engineer  what  kind 
of  relationship  two  ECs  have-positive,  negative  or  none.  For  example,  in  [CH88]  the 
signs  >/  and  x  denote  positive  and  negative  relationships  respectively.  However  there  is 
a  basic  problem  with  this  approach-  in  a  real  design  it  is  often  impossible  to  condense 
the  information  about  how  two  ECs  are  coupled  into  a  single  symbol  such  as  \/  or  x . 
Carelessly  abstracting  these  tradeoffs  can  lead  to  bad  designs.  We  use  the  drill  example 
to  illustrate  the  complexity  of  real  tradeoffs  and  suggest  an  alternative  way  of  storing  the 
coupling  between  ECs. 

Consider  for  example  the  two  ECs  max.  power  and  mass  in  Figure  3.  These  share 
many  common  variables  including  motor  choice,  and  number  of  cells.  In  situations  like 
this,  where  there  are  multiple  common  design  variables,  there  is  the  potential  for  the  two 
ECs  to  be  coupled  differently  with  respect  to  each  common  design  variable. 


For  example,  if  we  increase  number  of  cells,  the  values  of  mass  and  max.  power  go  up, 
which  are  undesirable  and  desirable  changes  respectively.  This  is  possibly  what  Clausing 
and  Hauser  [CH88]  mean  by  their  x  symbol.  However,  looking  at  motor  choice  we  see 
that  by  changing  its  value  from  brushed  to  brushless  it  is  possible  to  drive  mass  down  and 
power  up,  which  are  both  desirable  changes.  This  raises  the  question  of  how  to  represent 
the  overall  relationship  between  two  ECs  in  such  situations.  A  precise  semantics  must 
be  defined  for  any  terms  used  to  describe  the  relationship  between  two  ECs. 

For  example,  if  two  ECs  are  shown  as  related  by  a  \/  symbol,  does  this  mean  that 
whenever  one  of  the  ECs  is  increased  the  other  one  always  increases?  Such  an  assumption 
is  unjustified  in  most  cases  as  it  requires  that  a  stringent  mathematical  monotonicity 
criterion  be  fulfilled.  Since  this  is  rarely  the  case,  improperly  defined  symbols  can  be 
quite  misleading  and  adversely  affect  design  decision  making.  We  propose  that  the  roof 
of  the  HOQ  be  used  only  to  display  a  binary  indicator  of  whether  coupling  exists  or  not. 
The  most  obvious  way  of  checking  if  two  ECs  are  coupled  is  to  see  if  they  share  any 
design  variables  in  the  engineering  model.  It  can  be  easily  seen  from  Figure  3  that  mass 
and  max.  power  sha.Te  some  design  variables.  However  this  only  indicates  the  presence  of 
coupling  and  does  not  define  the  nature  of  the  coupling.  Another  level  of  analysis  such 
as  a  monotonicity  check  on  the  shared  variables  must  be  applied  to  detail  the  nature 
of  the  correlation.  This  information  may  be  displayed  in  a  table  with  an  entry  for  each 
common  design  variable.  Of  course,  if  the  couphng  varies  depending  on  the  values  of 
the  design  variables  the  engineering  model  must  be  used  to  evaluate  the  nature  of  the 
coupling  for  different  values  of  the  design  variables.  The  engineering  model  provides  a 
justifiable  mathematical  basis  for  deriving  the  nature  of  these  relationships. 

We  believe  that  by  combining  the  information  in  the  HOQ  and  the  engineering  models, 
designers  have  a  valuable  tool  for  managing  tradeoffs,  one  of  the  primary  tasks  required  of 
designers.  Once  the  engineering  model  is  used  to  understand  the  nature  of  the  tradeoffs 
between  ECs,  the  information  in  the  HOQ  can  be  used  to  complete  the  connection  with 
customer  perception. 


5      A  Single  Representation  for  both  HOQ  and  PDN 
Information 

We  propose  representing  all  information  related  to  both  the  HOQ  and  engineering  models 
in  a  single  representation  in  order  to  facilitate  the  kind  of  reasoning  described  above. 

An  appropriate  abstract  structure  for  storing  this  information  is  the  generalized  graph, 
which  uses  nodes  as  sites  for  storage  of  arbitrary  kinds  of  information  and  labeled  edges 
to  indicate  relationships  of  different  kinds  between  nodes.  These  simple  entities  can 
be  used  to  represent  all  the  information  currently  stored  in  the  HOQ  and  engineering 
models  shown  in  Figures  2  and  3.  Figure  4  shows  how  this  may  be  done.  It  shows  more 
details  about  the  graph  representation  of  the  HOQ  because  the  graph  structure  of  the 
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engineering  model  is  already  evident  from  Figure  3. 

In  practice,  the  graph  in  Figure  4  is  represented  in  the  computer  using  frames,  a  con- 
struct developed  in  artificial  intelligence  (AI)  research[Nil80].  The  frame  representation 
was  chosen  for  this  application  because  it  is  flexible  and  easy  to  understand,  implement 
and,  if  necessary,  extend.  A  frame  is  a  data  structure  that  contains  a  number  of  slots, 
each  of  which  can  be  assigned  a  value.  To  represent  a  graph,  a  frame  is  created  for 
each  node  in  the  original  graph  structure  and  all  the  information  stored  at  that  node, 
including  that  about  incident  edges,  is  represented  as  a  set  of  slot-value  pairs  belonging 
to  that  frame.  For  example,  each  frame  has  a  slot  called  name,  whose  value  is  a  unique 
identifier.  A  link  to  another  frame  can  be  represented  by  storing  the  name  of  the  linked 
frame  as  a  slot  value.  No  restriction  is  placed  on  the  value  of  any  slot  and  hence  multiple 
values,  lists,  links  to  multiple  frames  etc.  can  be  easily  handled.  All  the  frames  are  stored 
in  a  database  and  by  searching  this  database  appropriately  all  the  information  originally 
stored  in  the  graph  structure  can  be  retrieved.  Figure  4  also  shows  a  sample  frame  for  a 
CA  and  an  EC  node. 

Two  specific  points  to  note  about  the  frame  representation  are  as  follows, 

•  The  frames  for  the  CAs,  ECs  and  design  variables,  despite  different  appearances, 
are  in  fact  similar,  differing  only  in  the  types  and  values  of  slots. 

•  Arbitrary  information  can  be  stored  in  each  frame.  For  example,  if  a  designer  wants 
to  store  any  additional  textual  information  such  as  the  name  of  the  city  where  the 
data  was  collected  with  each  customer  attribute,  this  can  be  easily  accommodated. 

We  have  implemented  a  system  that  supports  creation  and  manipulation  of  frames 
for  storage  of  design  information.  This  system  has  features  similar  to  many  research 
and  commercial  frame-based  systems  and  is  implemented  using  the  LISP  programming 
language.  The  wide  variety  of  computational  structures  that  can  be  easily  created  in 
LISP  as  well  as  the  availability  of  an  interactive  interpreted  environment  were  some  of 
the  important  features  that  guided  this  choice.  The  implementation  is  fairly  standard 
(see  for  example,  [CRM80])  and  hence  details  of  it  are  omitted.  The  designer  is  provided 
with  the  following  basic  facilities, 


•  A  means  of  creating  and  examining  frames  of  arbitrary  size  and  nature  in  a  variety 
of  ways  -  through  input  of  formatted  text  files,  by  using  a  graphical  editor^  or  by 
typing  LISP  commands  to  the  interpreter. 


• 


Access  functions  that  allow  the  user  to  retrieve  and  display  information  from  the 
representation.  For  example  to  list  all  the  ECs  related  to  a  particular  CA  (and  vice 
versa). 


Not  implemented 
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ENGINEERING 
MODEL 


CA  NAME:  TOOL  IS  EASY  TO  HANDLE 
RELATED  ECS:  MASS  9 
RELATIVE  IMPORTANCE:  20 

•  •  • 


EC  NAME:  MASS 

RELATED  CAS:  CAN  USE  TOOL  CONTINUOUSLY  3 
TOOL  IS  EASY  TO  HANDLE  9 

IMPUTED  IMPORTANCE:  1.13 

UNITS:  KG 

COMPETITOR: 

TARGET: 

INTERMEDIATE  VARIABLES: 

MOTOR  MASS,  BATTERY  MASS, 
TRANSMISSION  MASS,  HEAT  SINK  MASS 

RELATED  DESIGN  VARIABLE: 

MOTOR,  NUMBER  OF  CELLS,  TRANSMISSION 
RATIO,  NUMBER  OF  SPEEDS,  HEAT  SINK  SIZE 

•  •  • 


Figure  4:  HOQ  for  design  of  cordless  drill 
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•  Access  to  the  full  power  of  the  underlying  LISP  programming  language  which  can 
operate  directly  on  the  frame  representation  and  be  used  to  perform  analyses  of 
arbitrary  complexity. 

Using  a  single  representation  does  not  in  itself  add  any  new  theoretical  capability  that 
could  not  be  achieved,  however  awkwardly,  by  placing  printouts  of  the  HOQ  and  the  engi- 
neering model  side  by  side  on  a  table.  We  believe  the  real  benefit  of  the  unified  represen- 
tation is  the  change  we  hope  it  will  cause  in  the  way  this  information  is  perceived-what 
was  previously  mentally  labeled  "marketing"  and  "engineering"  will  henceforth  simply 
be  "product  design  information".  We  also  believe  that  a  unified  representation  of  the 
information  will  facilitate  bookkeeping,  calculations,  and  other  necessary  manipulation. 


6      Conclusion 

6.1      Summary  of  current  work 

The  aim  of  this  paper  is  to  discuss  the  following  practical  difficulties  we  encountered 
using  the  HOQ  methodology, 

•  If  the  customer  and  competitor  information  in  the  HOQ  alone  is  used  to  set  engi- 
neering targets,  these  targets  are  often  unreachable. 

•  Using  a  single  symbol  in  the  roof  of  the  HOQ  to  represent  the  coupling  between 
ECs  is  an  extreme  oversimplification  of  reality,  where  ECs  are  coupled  in  multiple 
and  complex  ways. 

We  have  proposed  that  these  problems  can  be  solved  if  the  HOQ  is  augmented  with  the 
information  stored  in  the  engineering  models  used  by  the  designers.  In  many  product 
design  situations,  engineering  models  are  already  available  and  hence  can  be  readily 
integrated  with  the  HOQ.  We  have  further  suggested  that  in  addition  to  combining  this 
information  when  reasoning  about  the  design,  some  benefit  can  be  derived  from  using  a 
single  representation  for  information  contained  in  the  HOQ  and  the  engineering  models. 

In  addition  to  fixing  the  two  problems  mentioned  above,  we  believe  there  are  several 
peripheral  benefits  of  this  methodology. 


• 


• 


The  true  character  of  the  design  problem  is  more  accurately  represented  since  the 
directly  controllable  quantities,  the  design  variables,  have  been  linked  to  the  critical 
output,  customer  perception. 

The  combined  information  can  be  used  as  an  effective  tool  for  guiding  design  im- 
provements because  the  design  variable  with  the  maximum  beneficial  effect  on 
customer  perception  can  be  reliably  located. 
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•  Better  organizational  integration  is  prompted  by  the  closer  link  between  the  mar- 
keting and  design  functions,  also  resulting  in  more  focussed  engineering  modeling 
and  customer  data  collection  efforts. 

•  The  number  of  places  in  the  development  process  where  subjective  judgments  must 
be  made  is  reduced. 

•  The  integrated  representation  facilitates  the  documentation  of  design  decisions. 

Finally,  on  the  subject  of  structured  methodologies  for  design,  we  believe  that  it  is 
important  to  distinguish  the  ends  and  the  means.  The  end  is  to  explicitly  take  account 
of  potential  or  existing  customers  when  designing  a  product  so  as  to  eventually  achieve  a 
product  that  better  satisfies  their  needs.  The  means  are  structured  methodologies.  Any 
one  of  the  several  available  and  proven  techniques  can,  if  applied  thoughtfully,  be  used 
successfully  in  a  design  project.  It  is  important  to  regard  structured  methodologies  in 
this  light  and  not  to  treat  them  as  dogma  or  guaranteed  recipes  for  successful  design. 


6.2      Future  work 

This  research  is  still  embryonic  and  important  questions  remain  about  the  applicability 
of  the  ideas  presented  in  this  paper.  Some  of  these  are: 

•  Can  they  be  scaled  for  application  to  large  problems? 

•  Can  they  be  applied  in  the  context  of  a  real  organization? 

This  question  can  only  be  addressed  through  practical  experience  and  hence  we  do  not 
attempt  to  prove  or  disprove  them  at  this  stage.  We  are  currently  involved  in  applying 
these  ideas  to  a  two-year  design  project,  which  began  in  September,  1991  at  MIT.  The 
project  is  aimed  at  working  in  conjunction  with  an  industrial  sponsor  to  design,  develop 
and  market  an  innovative  power  tool.  The  results  of  this  endeavor  are  forthcoming  and 
we  hope  to  describe  further  results  based  on  real  experience. 
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